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patterns  in  the  sequence  of  'knowledge  applications'  and 
which  compile  descriptions  of  these  patterns  in  a control 
language,  called  CRAPS.  More  specifically,  pattenis  of 
repeating,  parallel  and  common  sequences  are  considered  in 
the  analysis.  The  CRAPS  descriptions  generated  are  then  used 
for  guidance  in  solving  subsequent  problems.  We  discuss  the 
utility  of  such  an  approach  and  give  an  example  of  a generated 
CRAPS  description. 
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Abstract 

— A 

^""^During  the  last  few  years  a number  of  relatively  effective  AI  programs 
have  been  written  incorporating  considerable  amounts  of  problem  specific 
knowledge.  Consequently,  the  problem  of  encoding  such  knowledge  in  a useful 
form  has  emerged  as  one  of  the  central  problems  of  AI.  In  particular, 
Declarative  representations  of  knowledge  have  attracted  much  attention  partly 
because  of  the  relative  ease  with  which  knowledge  can  be  communicated  in 
this  form.  Unfortunately,  implementation  of  Declaratively  specified  knowl- 
edge corresponds  to  a non-deterministic  program  which  incurs  enormous  compu- 
tational  costs. 

c*This  paper  discusses  one  way  to  limit  this  cost.  The  approach  we  take 
is  to  develop  control  heuristics  for  a family  of  problems  from  traces  of 
sample  solutions  generated  during  a training  session  with  a human  expert. 
Algorithms  have  been  developed  which  recognize  a predefined  set  of  patterns 
in  the  sequence  of  'knowledge  applications'  and  which  compile  descriptions 
of  these  patterns  in  a control  language,  called  CRAPS.  More  specifically, 
patterns  of  repeating,  parallel  and  common  sequences  are  considered  in  the 
analysis.  The  CRAPS  descriptions  generated  are  then  used  for  guidance  in 
solving  subsequent  problems.  We  discuss  the  utility  of  such  an  approach  and 
give  an  example  of  a generated  CRAPS  description. 


1.  Introduction 


During  the  last  few  years,  a number  of  relatively  effective 
Artificial  Intelligence  programs  have  been  written  incorporating 
considerable  amounts  of  knowledge,  and  the  problem  of  encoding 
such  knowledge  in  a useful  form  has  emerged  as  one  of  the  central 
problems  of  AI.  Winograd  [ 16}  distinguishes  between  declarative 
information  which  can  be  thought  of  as  "knowing  what",  and  procedural 
information  which  can  be  thought  of  as  "knowing  how".  He  describes 
the  underlying  problem  as  that  of  constructing  representations 
which  can  take  advantage  of  the  decomposability  of  the  declarative 
representation  without  sacrificing  the  interactive  possibilities  of 
the  procedural  representation.  Ideally,  it  should  be  possible  to 
specify  information  in  a form  which  does  not  constrain  the  way  in 
which  it  is  to  be  used;  unfortunately,  a straightforward 
implementation  of  such  a declarative  representation  corresponds  to 
a non-deterministic  program  which  makes  a relatively  blind  search 
through  the  solution  space. 

More  recently,  attention  has  turned  towards  mechanisms 
which  facilitate  incorporating  limited  procedural  or  heuristic 
information  into  a primarily  declarative  framework.  For  example, 
Rychener's  approach  [9  ] is  to  build  a rational  "goal"  structure 
into  declarative  rule-based  systems,  while  Davis  [2  ] favors  a 
separate  set  of  "meta-rules"  specifying  control  information.  In 
some  we  might  expect  that  the  amount  of  procedural  information 

is  of  the  same  order  of  magnitude  as  the  amount  of  declarative 
information,  and  so  ruch  approaches  may  be  effective.  However,  in 
most  cases  the  amount  o t control  information  will  be  very  large 


(e.g.  theorem-proving,  natural  language  understanding) . 

Thus  the  problem  of  acquiring,  debugging  and  extending  control 
information  will  become  increasingly  important. 


In  general,  we  might  expect  that  this  control  information 

% 

will  embody  very  sophisticated  principles  requiring  data-structures 
not  present  in  the  declarative  form  of  the  program,  or  which  are 
only  deducible  by  the  use  of  considerable  intelligence.  For  example,  • 
it  is  clear  that  the  incorporation  of  the  heuristic  principles  of 


evaluation  and  u-0  search  into  a declarative  chess  program  which 
specifies  only  the  rules  of  chess  but  no  strategies  for  playing 

will  require  an  analysis  which  is  considerably  beyond  the  ability 

. 

of  present  techniques;  even  the  optimization  of  the  parameters  in 

a linear  evaluation  function  involves  highly  sophisticated  processing. 

. 

However,  we  believe  that  there  are  a number  of  important 
areas  in  which  it  might  be  possible  to  deduce  control  information 
automatically  from  a declarative  program.  These  include  declarativeiy 
specified  problems: 

• for  which  there  exists  a relatively  simple  algorithmic 

I 

procedure ; 

• whose  performance  can  be  improved  in  frequently  occurring 
or  particularly  important  special  cases; 

• in  which  particular  subproblems  can  be  solved  by  simple 
algorithmic  procedures. 


I 


Some  work  on  this  problem  was  reported  by  Fikes,  Hart  and  Nilsson 
[4] . In  their  system,  STRIPS,  sequences  of  operator  applications 
used  in  solving  sample  problems  were  stored  for  possible 
guidance  (or  planning)  in  solving  subsequent  problems,  in  this 
paper  we  report  on  a somewhat  different  approach,  which  stresses 
the  importance  of  a deeper  analysis  of  the  sequence  of  operator 
applications.  A similar  approach  has  been  adopted  by  Phillips  [8] . 


A Sample  Problem 


As  an  example,  consider  the  following  problem.  Suppose  we 
want  to  solve  a (slightly  idealized)  jig-saw  puzzle,  in  which  each 
piece  has  an  average  color,  and  four  sides  described  by  unique 
integers  (with  side  i fitting  side  -i) . We  consider  below  a 
non-deterministic  algorithm  written  in  production  language  form. 

An  informal  description  of  the  productions  we  might  use  would 
include: 


START- PUZZLE:  If  there  is  no  puzzle  currently  being  built  and 

you  are  holding  a piece,  then  you  can  make  this  piece  the  first 
part  of  the  puzzle,  leaving  your  hand  empty.  Notice  that  you 
continue  to  look  at  the  piece. 

J.OOK-AT-PIECE- IN-HEAP:  If  a piece  is  in  the  heap  then  you  can  look 

at  it. 

PICK-UP-OBJECT— IN-VIEW:  If  you  are  looking  at  an  object  and 

holding  nothing,  then  you  can  pick  up  the  object.  Its  position 
changes  to  being  in  your  hand. 

LOOK-AT-OBJECT- IN-HAND:  If  something  is  in  your  hand,  then  you 

can  look  at  it. 

CLOSE-EYES:  If  you  are  looking  at  something  which  is  not 

NOTHING  then  you  can  look  at  NOTHING. 

OBJECT- IN-HAND- IN-VIEW:  This  production  senses  when  the  object 
being  held  is  in  view  without  performing  any  actions. 

FIND-COLOR-OP-PIECE:  If  you  are  holding  a puzzle  piece,  you  can 

look  at  it  and  know  its  color. 

PIECE-HAS-CURRENT-COLOR:  This  senses  when  the  object  being  held 
has  the  current  color  you  are  considering. 


FORGET-COLOR-OF-PIECE:  If  a piece  is  in  view  and  you  know  its 

color,  you  can  look  away  from  it  and  forget  the  color. 

PIECE-HAS-STRAIGHT-EDGE : This  production  senses  when  the  piece 


*f  *»  • V •«  « «n  i mV  A. 

a*  * AS.W  AIUO  U OkiaiMilL 


- J 

cuuc. 


PUT-PIECE-DOWN- IN-HEAP:  If  you  are  holding  a puzzle  piece,  you 
can  put  it  in  the  heap  awl  yni’r  hand  is  empty.  Notice  that  the 
piece  continues  to  be  in  view. 
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HEAP- IS- EMPTY:  This  senses  if  the  heap  is  empty. 

PIECE-FITS-IN-PUZZLE:  This  production  senses  when  a puzzle 
piece  that  is  in  view  will  fit  another  puzzle  piece  already 
in  the  puzzle. 

FIT-PIECE-IN-PUZZLE:  If  the  piece  being  held  and  in  view  fits 

in  the  puzzle,  the  sides  of  the  matching  pieces  can  be  joined. 

PIECE-PUT- IN- PUZZLE:  If  you  are  holding  a puzzle  piece,  which 
is  being  placed  in  the  puzzle,  you  could  put  it  down  in  the 
puzzle. 

PUZZLE-IS-FINISHED:  If  all  of  the  pieces  are  in  the  puzzle,  you 
can  halt. 

The  complete  program  is  given  in  Appendix  I. 

It  should  be  noted  that  this  representation  is  highly 
non-deterministic,  and  if  executed  would  be  hyper-exponentially 
inefficient.  It  does  not  even  "know"  that  it  will  find  a 
solution  (i.e.  terminate)  if  it  can  repeat  the  production 
PUT-PIECE- IN- PUZZLE  as  frequently  as  possible,  so  even  the 
crudest  goal-subgoal  structure  is  absent.  (However,  there  is 
no  production  to  remove  a piece  from  the  puzzle,  which  serves?  as 
a clue  to  an  intelligent  observer) . It  is  even  possible  for  the 
program  to  pick  up  a piece  and  then  put  it  down  immediately 
without  doing  anything  with  it. 

The  performance  of  this  program  could  be  improved  to  a 
tolerable  level  if  the  following  heuristic  was  added: 

. use  the  following  sequence  repeatedly 
pick  up  a piece  from  the  heap; 
insert  it  in  the  puzzle  if  it  fits. 

An  alternative  heuristic  would  be: 

. use  the  following  sequence  repeatedly 
locate  a piece  p in  the  puzzle  with  a missing  neighbor; 
pick  up  pieces  from  the  heap  until  one  matches  p,  and 
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insert  it  in  the  puzzle. 

Each  of  these  heuristics  is  very  simple,  consisting  mainly  of 
sequencing  rules  for  the  productions,  and  would  seem  to  be 
within  the  range  of  automatic  inference.  A further  improvement 
could  be  made  by  noting  that  the  procedure  for  selecting  a piece 
from  the  heap  is  inefficient  since  the  same  piece  may  be  selected 
repeatedly  (and  in  a production  system  such  as  that  of  Rychener 
[10]  which  prefers  to  use  recently  referenced  items  in  working 
memory,  in  other  respects  a reasonable  strategy,  the  search  will 
almost  always  be  ineffective) . If  we  add  a few  more  productions, 
it  becomes  possible  for  the  system  to  search  systematically 
through  the  heap  by  constructing  a pile  from  the  pieces  in  the 
heap,  and  putting  a piece  down  in  a different  pile  when  it  has 
looked  at  it. 

MAKE-A-PILE:  If  you  want  to  make  a pile  and  you  are 

holding  something,  put  it  in  the  pile  and  your  hand  is  empty. 

The  object  continues  to  be  in  view., 

PICK-A-PILE:  If  you  are  not  working  with  a pile,  just  pick 

the  first  one. 

PICK-OBJECT-FROM-PILE:  To  pick  an  object  from  a pile,  if  your 

hand  is  empty  reach  in  and  pick  up  the  first  one  you  see. 

PUT-OBJECT-IN-PILE:  To  put  an  object  in  a pile,  if  you  are 
holding  something,  just  place  it  in  the  back  of  the  pile  and 
your  hand  is  empty. 

FORGET-THIS-PILE:  To  forget  a pile,  just  push  the  current  pile 
behind  all  the  others. 

PILE-IS-EMPTY:  A pile  is  empty  , if  there  is  nothing  on  it. 

DSCTROY-A-riLE:  To  destroy  the  current  pile,  just  strike  it 
from  memory. 

THERE-ARE-NO-PILES:  There  are  no  piles  if  all  the  piles  were 

destroyed. 


LOOK-AT-FIRST- IN-PILE:  If  there  is  an  object  at  the  front  of 
the  pile,  you  can  focus  on  it. 

LOOK-' AT-NEXT- IN-PILE:  If  you  want  to  scan  through  a pile  and 
you  are  looking  at  the  first  object  in  it,  focus  on  the  next 
one  by  placing  the  first  object  behind  the  last. 

The  actual  pile  productions  can  be  found  in  Appendix  II. 

The  pile  productions  are  very  general,  and  might  be 
expected  to  be  present  in  any  system;  indeed,  it  seems  likely 
that  productions  for  dealing  with  heaps  and  piles  (i.e.  sets  and 
tuples)  and  heuristics  for  implementing  important  operations  such 
as  searching  will  be  present  in  production  systems  as  they  are 
in  modern  programming  languages  [3] . 

Carrying  our  jig-saw  puzzle  a step  or  two  further,  sufficient 
productions  are  present  now  to  permit  simple  sequencing  heuristics 
to  reflect  the  usual  strategies  used  by  experienced  puzz?.c— solvers 
. work  on  the  outside  edges  first  (build  a pile  of  outside 
edges) ; repeat  the  PUT-PIECE-IN-PUZZLE  sequence  until  this  pile 
is  empty; 

. separate  the  pieces  in  the  heap  into  piles  of  the  same 
average  color,  and  search  the  appropriate  pile  first; 

. search  first  for  pieces  which  have  more  than  one  neighbor 
of  the  same  average  color  (e.g.  work  on  the  sky  first); 

It  may  appear  that  automatic  detection  of  such  heuristics  is  a 
task  of  great  difficulty.  Below  we  outline  an  approach  to  this 
problem  which  we  believe  can  be  quite  successful,  describe  a 
system  which  has  been  embeeded  in  PROSYS,  an  extension  of 
OPS 2 {51 , and  give  some  preliminary  results. 


3.  Approach 


Our  procedure  is  as  follows:  we  select  a 'typical'  input 
to  the  program  and  run  the  program  repeatedly  on  this  input, 
recording  the  sequence  of  rules  selected.  This  is  repeated  for 
other  typical  inputs.  We  then  attempt  to  describe  the  better 
(i.e.  shorter)  successful  sequences  in  a language,  CRAPS, 
designed  for  this  purpose  and  described  in  the  next  section. 

We  then  use  this  description  to  guide  the  program's  subsequent 
decisions. 

Inherent  in  this  approach  is  the  assumption  that  good 

decision-making  procedures  or  heuristics  can  be  inferred  from 

the  performance  of  the  program  on  only  selected  inputs.  In 

general,  as  suggested  by  work  or  inductive  inference  [17]  and 

information  theory  [1,6,11],  we  will  give  preference  to  short 

0 

CRAPS  descriptions  which  will  generate  a high  proportion  of 
short  successful  solutions  and  few  long  or  unsuccessful  solutions. 
We  anticipate  that  the  selection  of  inputs  will  be  critical  and 
that  eventually  we  will  want  to  be  able  to  handle  new  inputs 
incrementally,  as  was  done  in  [17] . Initially,  however,  wo  will 
concentrate  on  the  simpler  problem  of  getting  a good  solution 
for  the  non- incremental  case. 

As  suggested  by  the  example  in  section  2,  the  execution-time 
of  a completely  declarative  program  will  usually  be  too  long  to 
permit  a solution  except  in  the  simpler  cases.  Accordingly, 
we  will  run  the  program  in  "training  mode"  in  which  its  decisions 
can  be  observed  and  if  necessary  corrected.  In  initial  experiments 
this  will  be  done  by  a trainer  who  is  aware  of  the  structure  of 
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the  program;  subsequently  we  anticipate  the  necessity  of  using 
techniques  similar  to  those  of  Davis  [2],  which  will  enable 
the  trainer  to  deal  only  with  the  external  behavior  of  the 
program. 

It  should  be  noted  that  we  have  deliberately  chosen  to  exclude 
information  about  sequences  which  end  in  failure.  It  is  clear 
that,  as  found  by  Winston  in  other  inductive  inference  work  117] , 
counter-examples  will  be  extremely  valuable.  However,  as  the 
reader  will  note  below,  even  this  simpler  problem  poses  considerable 
technical  difficulties,  and  it  was  our  feeling  that  a clearer 
picture  would  emerge  from  the  simpler  approach.  Furthermore, 
initial  experiments  described  in  section  5 suggest  that  useful 
results  can  be  obtained  without  counter-examples. 


4 . The  CRAPS  language 


The  CRAPS  language  provides  a semantic  framework  with  which 
to  specify  or  describe  sequences  of  rule  applications  in  the 
execution  of  the  non-deterministic  program.  The  most  basic 
primitive  of  CRAPS  is  called  a unit.  A unit  specifies  either  a 
rule  application  with  preconditions , or  a control  operation 
applied  to  a sequence  of  units.  The  control  operations  are: 

(1)  Concatenation  of  units  producing  sequences; 

(2)  Repetition  of  a sequence  of  units  controlled  by 
Boolean  conditions; 

(3)  Alternative  (or  conditional)  selection  of  a sequence 
from  a set  of  sequences; 

(4)  Permutation  of  a set  of  sequences.  (Thus,  the 
acronym  CRAPS , ) 

Conditions  in  the  above  are  DNF  expressions  of  rules,  with  a 
rule  being  considered  true  if  it  is  fireable. 

The  operators  of  CRAPS  correspond  to  control  primitives  of 
conventional  programming  languages.  Concatenation  corresponds  to 
sequential  execution  of  statements,  and  repetition  corresponds  to 
iteration  statements  with  'while'  and  'until'  termination  condi- 
tions. The  alternation  operator  specifies  alternative  sequences 
of  actions  much  like  an  ALGOL-68  'case'  statement  or  LISP  'cond' 
expression.  The  permutation  primitive  represents  a form  of 
concurrent  execution  similar  to  the  specification  of  collateral 
expressions  in  ALGOL- 5 2 . 

An  example  of  a CRAPS  descriot ■Inn  can  he  found  in  section  5. 
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5.  An  Example:^  Binary  Tree  Traversal 

The  program  in  figure  1 has  the  ability  to  scan  a binary  tree  in 
any  order.  No  control  information  is  specified  in  any  of  the 
productions.  The  productions  have  been  chosen  to  encode  all  of 
the  relevant  information  about  scanning  a binary  tree  without 
specifying  direction. 

A binary  tree  is  represented  in  working  memory  by  the  following 
data  format.  The  root  of  the  tree  is  represented  by  (ROOT  *=X)  where 
«X  can  be  bound  to  any  symbol.  If  node  B has  a left  son  A,  it  is 
represented  by  (LEFT  B A)  and  similarly  (RIGHT  B C)  represents  C as 
the  right  son  of  B.  The  father  of  a node  (either  left  or  right)  is 
represented  for  example  by  (FATHER  B A) . The  current  node  being 
scanned  is  represented  by  (NODE  =X).  In  scanning  binary  trees,  nodes 
can  be  printed  only  once.  If  node  A has  been  scanned  and  printed, 
then  (ALREADY-P  A)  is  deposited  in  working  memory. 

Several  binary  trees  were  placed  in  working  memory  and  then  the 
programwas  initiated  and  directed  by  a human  to  scan  in-order  each 
tree.  A trace  for  each  execution  was  produced  (see  figure  2 for 
examples) . The  entire  set  of  traces  was  presented  to  the  pattern 
recognition  algorithms,  which  produced  the  CRAPS  description 
presented  in  figure  3 . The  integers  labelling  the  rule  names  in 
the  final  description  are  meant  to  differentiate  particular  in- 
stances of  rule  applications.  For  example  (15.  PRINT)  is  a 
completely  different  application  of  PRINT  than  i c {17.  PRINT) . 

In  this  particular  case  the  CRAPS  description  is  s precise 
definition  of  an  in-order  balanced  binary  tree  scan  program.  That 
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is,  given  a working  memory  specifying  a balanced  binary  tree,  the 
shortest  execution  sequence  of  the  program  which  would  result 
in  an  in-order  print  of  the  nodes  would  belong  to  the  set  of 
sequences  specif ied  by  the  CRAPS  description;  furthermore,  the 
CRAPS  description  provides  enough  information  to  determine  which 
production  should  be  fired  at  every  point  in  the  execution  of 
the  program.  Thus  a non-deterministic  program  has  in  effect 
been  reduced  to  a deterministic  program. 

In  general,  we  cannot  assume  that  the  CRAPS  description  will 
be  as  effective  as  this.  With  poor  training  sequences,  or  incorrect 
analyses  of  execution  traces,  CRAPS  descriptions  may  imply  heuristics 
which  are  not  helpful,  or  which  are  helpful  for  some  examples  and 
harmful  in  others.  The  initial  approach  we  implemented  was  that 
of  Rychener's.  The  existing  program  was  altered  by 
including  special  'tag'  or  'control  elements'  in  both  sides  of 
the  rules  to  reflect  the  control  information  in  the  description. 

This  approach  appeared  to  impose  too  high  a level  of  control 
affecting  much  of  the  quality  of  the  production  system  representa- 
tion which  makes  it  attractive.  Although  the  original  trees 
used  in  the  training  sequence  and  other  trees  were  able  to  be 
traversed  correctly,  several  other  instances  of  trees  were  not. 

This  has  led  us  tc  consider  Davis'  approach  of  "meta-rules"  with 
a probabilistic  component  to  them.  In  this  direction,  a CRAPS 
description  would  be  transformed  to  a set  of  rules  which  suggest 
preferences  of  rules  over  others  during  the  testing  and  selection 
process  on  each  execution  cycle.  We  are  currently  looking  at  ways 
of  doing  this. 
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Figure  1,  Binary  Tree  Scanning  Production  System 
START- POINTING 

[ (ROOT  -x)  -(NODE  = anything)  — > (NODE  =x)  ] 
GO-LEFT 


((NODE  -x) 

(LEFT  * x = y)  — > 

(<delete> 

(NODE  -x)) 

(NODE  -x)  (FATHER  »x  «y) 

. GO-RIGHT 
[ (NODE  -X) 

(RIGHT  — x = y)  — > 

(<delete> 

(NODE  = x)  ) 

(NODE  - y)  (FATHER  «=x  «=y) 

CAN-T-GO-LEFT 

I (NODE  ■ x)  -(LEFT  -x -anything)  — > ) 

CAN-T-GO-RIGHT 

[ (NODE  -x)  -(RIGHT  -x -anything)  — > ] 

PRINT 

I (NODE  ** x)  - (ALREADY-P  «x)  — > (<write>  -x)  (ALREADY-P  -x)  ) 

GO-UP 

l (NODE  «x)  (FATHER  »x  = y)  — > (<delete>  (NODE  =x))  (NODE  =y)  ] 
STOP 

I (NODE  =x)  (ROOT  «x)  — > (<delete>  (NODE  -x))  (<halt>)  ] 


\ 
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FIGURE  2.  SAMPLE  TRACES  FROM  BINARY  TREE  PS  RUN 


« 

(START-POINTING  NIL  <1>  (22))  $ 

(PRINT  (STOP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT ) (1  2)  <3  4)) 

(STOP  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  <1  4)  (56)) 

» 


<< 

(START-POINTING  NIL  (9)  (10  10) > 

(GO-LEFT  (STOP  PRINT  GO-RIGHT)  (9  10)  (11  13)) 

(PRINT  (GO-UP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (12  13)  (14  15)) 
(GO-UP  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (12  15)  (16  17)) 

(PRINT  (STOP  GO-LEFT  GO-RIGHT)  (9  17)  (18  19)) 

(GO-RIGHT  (STOP  GO-LEFT)  (9  19)  (20  22)) 

(PRINT  (GO-UP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (21  22)  (23  24) ) 
(GO-UP  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (21  24)  (25  26)) 

(STOP  (GO-LEFT  GO-RIGHT)  (9  26)  (27  28) ) 

» 


« 

(START-POINTING  NIL  (14)  (15  15)) 

(GO-LEFT  (STOP  PRINT  GO-RIGHT)  (14  15)  (16  18)) 

(GO-LEFT  (GO-UP  PRINT  GO-RIGHT)  (17  18)  (19  21 )> 

(PRINT  (GO-UP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (20  21)  (22  23)) 
(GO-UP  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (20  23)  (24  25)) 

(PRINT  (GO-UP  GO-LEFT  GO-RIGHT)  <17  25)  <26  27)) 

(GO-RIGHT  (GO-UP  GO-LEFT)  (17  27)  (28  30)) 

(PRINT  (GO-UP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (29  30)  (31  32)) 
(GO-UP  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (29  32)  <33  34)) 

(GO-UP  (GO-LEFT  GO-RIGHT)  <17  34)  <35  36)) 

(PRINT  (STOP  GO-LEFT  GO-RIGHT)  <14  36)  <37  38)) 

(GO-RIGHT  (STOP  GO-LEFT)  <14  38)  <39  41)) 

(GO-LEFT  (GO-UP  PRINT  GO-RIGHT)  (40  41)  <42  44)) 

(PRINT  (60-UP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  <43  44)  <45  46)) 
(GO-UP  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  <43  46)  (47  48)) 

(PRINT  (GO-UP  GO-LEFT  GO-RIGHT)  (40  48)  <49  50)) 

(GO-RIGHT  (GO-UP  GO-LEFT)  (40  50)  <51  53)) 

(PRINT  (GO-UP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  (52  53)  (54  55) ) 
(GO-UP  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  <52  55)  <56  57)) 

(GO-UP  (GO-LEFT  GO-RIGHT)  <40  57)  <58  59)) 

(STOP  (GO-LEFT  GO-RIGHT)  <14  59)  (60  61)) 

» 


i 

i 

! 
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FIGURE  3.  SAMPLE  CRAPS  OUTPUT  FROM  BINARY  TREF  PS  RUN 


« 

<<0  . START-POINTING)  NIL) 

C IF  (GO-LEFT  STOP  PRINT  GO-RIGHT)  THEN 

« 

CREPEAT  (WHILE  (GO-LEFT  GO-RIGHT)) 

(UNTIL  NIL) 

« 

CREPEAT  (WHILE  (GO-LEFT  GO-RIGHT)) 

(UNTIL  (CAN-T-GO-LEFT  CAN-T-GO-RIGHT > ) 

« 

((13  . GO-LEFT)  (STOP  PRINT  GO-RIGHT)) 

» 

3 

CREPEAT  (WHILE  (CAN-T-GO-LEFT  CAN-T-GO-RIGHT)) 

(UNTIL  (GO-LEFT  GO-RIGHT)) 

« 

((15  . PRINT)  (GO-UP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT ) ) 
CREPEAT  (WHILE  (GO-UP)) 

(UNTIL  (PRINT  STOP)) 


« 

((16  . GO-UP)  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)) 

» 

3 

((17  . PRINT)  (GO-UP  GO-LEFT  GO-RIGHT)) 

((18  . GO-RIGHT)  (GO-UP  GO-LEFT) > 

» 


3 

» 

3 

» 

ELSEIF  TRUE  THEN 

« 

» 

3 

((1  . PRINT)  (STOP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT)) 

C IF  (GO-UP  CAN-T-GO-RIGHT  CAN-T-GO-LEFT)  THEN 

« 

CREPEAT  (WHILE  (GO-UP)) 

(UNTIL  (STOP)) 

« 

((30  . GO-UP)  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)) 

» 

3 

» 

ELSEIF  TRUE  THEN 

« 

» 

3 

( (2  . STOP)  (CAN-T-GO-RIGHT  CAN-T-GO-LEFT)) 


IS 


6.  Algorithms 


In  this  section  we  outline  the  algorithms  which  produce 
CRAPS  descriptions  from  a set  of  sequences  of  rule  applications 
which  solved  a particular  family  of  problems.  The  exact  form 
of  an  input  sequence  is  <<  PI  P2  ....  >>,  where  Pi  is  of  the 

• t * 

form  (Pi  (piipi2*  • *pini^  *nilni2*  • *nij)  (°il°i2^'  where  Pi  is  the 
rule  which  was  applied  on  the  i'th  cycle  of  execution.  (pilpi2** 

.pim)  is  the  list  of  rules  which  were  applicable  on  the  ith  cycle 
and  describes  the  data  environment  at  that  point  in  the  execution. 
^nilni2*  * *nij ' the  **-st  of  unique  numbers  associated  with  the 
instances  of  data  elements  which  matched  the  rule  p|,  and  (ojjOj^) 
is  the  range  of  numbers  associated  with  the  data  elements  deposited 
in  working  memory  by  the  application  of  rule  P^.  The  sequence 
presented  is  an  exact  history  of  the  execution  of  the  program  and  is 
therefore  already  partially  ordered  by  the  back  dominance  relation. 
This  makes  the  subsequent  pattern  recongnizing  easier. 

The  initial  approach  we  considered  to  finding  permutations  of 
rule  applications  in  the  sequences  was  to  do  a static  analysis  of 
the  rules  to  determine  which  rules  were  permutable,  i.e.,  which 
rules  produced  output  that  could  not  be  input  by  other  rules. 

This  approach  was  found  to  be  too  difficult  and  not  general  enough. 
Instead,  we  use  techniques  similar  to  those  developed  for  program 
optimization.  Using  the  input/output  information  contained  in  the 
trace,  a data  flow  directed  acyclic  graph  (hag)  is  constructed 
whose  nodes  correspond  to  rule  applications  and  whose  edqes  represent 
the  flow  of  data  from  one  rule  to  another.  This  DAG  completely 
specifies  all  of  the  data  dependencies  and  therefore  all  of  tne 
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possible  execution  sequences.  After  the  DAG  is  cleansed  of 
irrelevant  forward  arcs  (see  Tarjan  (13,14,15]),  it  is  linearized  to  a 
CRAPS  description  employing  permutation  and  simple  units  only.  The 
construction  of  permutations  is  based  on  the  observation  that  if 
a node  has  two  or  more  entering  edges  then  the  subsequences 
associated  with  its  predecessors  can  be  permuted.  A simple 
sequential  scan  of  the  nodes  in  the  E»AG  according  to  the  partial 
ordering  is  sufficient  to  produce  a linear  description  in  linear  time. 

The  next  processing  is  the  detection  of  repeating  subsequences 
and  formation  of  repetition  units.  Unlike  the  permutation 
detection  problem,  which  is  well-defined,  and  which  is  solved  by 
the  algorithm  described  above,  some  sequences  may  have  several 
equally  acceptable  descriptions  using  the  repetition  operator.  The 
algorithm  we  use  gives  one  description.  We  first  scan  the  sequence 
identifying  all  unique  units.  All  such  units  cannot  be  part  of  a 
repetition  and  thus  divide  the  sequence  into  shorter  subsequences  to 
which  the  entire  procedure  can  be  applied  recursively.  Once  a 
candidate  subsequence  is  found  (every  unit  in  it  appears  at  least 
twice) , we  scan  from  left  to  right  repeatedly  looking  for  equivalent 
adjacent  subsequences  replacing  them  by  repetition  units.  The 
procedure  stops  when  it  considers  lengths  greater  than  one  half  the 
current  length  of  the  sequence. 

The  final  operation  to  be  done  is  the  coalescing  of  several 
descriptions  produced  by  the  above  processing  into  one  description 
employing  the  alternation  operator.  The  construction  we  consider  ip 
similar  to  that  of  Winston  and  Hayes-Roth.  From  two  or  more 
descriptions  of  some  object  we  identify  the  points  of  similarity 
and  alternate  the  differences.  Sin^e  Lhis>  problem  is  equivalent 


to  the  Longest  Common  Subsequence  problem,  which  is  known  to  be 
NP-Complete  (See  Maier  [7  ]),  our  approach  is  highly  heuristic. 

The  computation  of  a common  subsequence  is  performed  by  a 
concurrent  left  to  right  scan  of  all  sequences  with  a heuristic 
weighting  function  which  gives  preference  to  repitition  units  over 
permutation  units  and  simple  rule  application  units. 

The  conditions  for  repetition  and  alternation  units  are 
computed  by  simple  set  expressions  on  the  list  of  applicable  rules 
( (Pill’i2. . .Pjjn)  above)  at  the  time  a set  of  subsequences  are 
collapsed  into  a unit.  The  final  output  of  these  algorithms  is 
fed  back  to  the  production  system  interpreter  and  used  for 


7 . Conclusion 


It  is  believed  by  many  researchers  that  an  important  quality 
of  intelligent  behavior  is  the  ability  to  improve  performance 
with  experience,  and  that  generalizing  a concept  is  a critical 
aspect  of  learning.  In  CRAPS,  a form  of  generalization  occurs 
when  a repeating  subsequence  is  collapsed  into  a repetition  unit. 
Although  quite  restricted  in  scope,  CRAPS  shows  how  a system  might 
learn  procedures,  a form  of  learning  which  we  believe  is  very 
important.  Although  there  are  a number  of  very  difficult  technical 
problems,  it  seems  to  us  that  with  more  powerful  pattern  recogni- 
tion techniques  and  more  powerful  generalizations  of  control 
statements,  this  approach  could  be  very  fruitful. 

With  less  ambitious  designs,  CRAPS  can  be  viewed  as  a 
programming  aid  for  the  designer  and  implementer  of  a large  AI 
problem-solving  knowledge  base.  The  CRAPS  approach  might  be 
useful  in  fine-tuning  a declarative  knowledge  base  as  opposed  to 
'hand-compiling'  control  elements  to  effect  competent  performance 
in  such  a system. 

The  power  of  the  descriptions  produced  is  limited  by  both 
the  expressive  power  of  the  CRAPS  primitives,  and  the  level  of 
sophistication  of  the  pattern  recognition  algorithms  that  have 
been  developed.  For  example,  during  repetition  detection  no 
notion  of  similar  subsequence  is  used;  rather,  a subsequence  must 
appear  exactly,  which  prevents  alternation  units  from  appearing 
Within  repetitions.  Despite  this,  the  algorithms  ere  powerful 
enough  to  detect  interesting  patterns  and  subsequently  interesting 
Heuristics. 


Our  experiments  suggest  that  this  approach  will  have  the 
best  chance  of  success  when  the  encoding  of  the  knowledge  of  the 
problem  domain  is  such  that  on  any  execution  cycle  a small  number 
of  productions  and  only  one  instantiation  of  each  production  is 
applicable.  This  suggests  one  way  in  which  CRAPS  should  evolve: 
the  execution  traces  should  include  not  only  productions  but 
also  the  instantiations  of  productions.  However,  recognizing 
patterns  in  the  sequences  which  include  data  is  a much  more 
difficult  problem.  We  view  our  approach  as  an  initial  step  in 
the  understanding  of  this  more  general  problem. 


APPENDIX  I 


Jigsaw  Puzzle  Production  System 

In  what  follows*  data  elements  can  be  any  LISP  data  structure. 
An  atomic  data  element  must  match  exactly  and  a list  must  match  a 
list  with  the  same  structure  and  content.  A symbol  preceded  with 
an  actuals  sign  (=)  represents  a variable  which  can  match  any  data 
structure.  The  $ symbol  contained  in  productions  has  the  same 
function  as  the  SNQB0L4  conditional  assignment  operator  (.).  When 
a rule  is  fired*  the  data  elements  are  not  deleted  from  working 
memory  unless  they  are  included  as  arguments  to  the  <delete>  system 
function  in  the  right  hand  side  of  the  rule.  The  other  system 
functions  contained  in  the  rules  are  represented  in  lower  case  end 
enclosed  by  pointed  brackets  (<  >>.  Their  function  is  described 
by  their  names.  The  symbol  ! is  an  operator  which  matches  the 
entire  remaining  portion  of  the  list  following  it.  Where  it 
appears  in  the  right  hand  side*  it  deposits  the  list  that  matched 
but  it  strips  away  the  enclosing  parentheses. 


Working  Memory  Eiata  Elements! 


1.  (PIECE  p c)  represents  a puzzle  piece  where  p is  a unioue  integer 
associated  with  a Piece  and  c is  its  average  color.  We  will  assume 
the  machine  knows  at  any  time  where  piece  p is  located  and  so  we 
ignore  location  in  the  representation. 


2.  (SIDE  s p n c)  represents  the  side  of  a puzzle  piece,  s is  either 
LEFT*  RIGHT*  TOP  or  BOTTOM  of  piece  p.  Since  location  is  ignored* 
rotation  of  a piece  in  space  is  also  ignored,  n is  an  integer 
representing  the  shape  of  the  side  where  +n  mates  with  -n  and  0 
represents  a straight  edge,  c is  the  color  of  the  edge.  The 
representation  could  easily  be  extended  to  represent  a vector  of 
colors  for  a series  of  points  on  the  edge. 


3.  (NUMBER-OF-PIECES  n>  states  that  n is  the  total  number  of  puzzle 
pieces. 

4.  (JOINED  (sidel  side?)  (side3  side4)...)  represents  the  sequence 
of  sides  thzt  were  jcirtcd  ir<  forming  the  ? uzzla. 

is  of  the  form  2 above. 

1.1 


'■ 1 * * 


1 


5.  < IN-PUZZLE  (PIECE  p c))  states  that  Piece  p is  in  the  puzzle* 

6.  (NUMBER-- IN-PUZZLE  n)  states  that  n is  the  number  of  puzzle  Pieces 
that  are  in  the  puzzle* 

7.  (CURRENT- COLOR  c)  represents  the  current  color  of  cr.  object  being 
considered. 

8.  (HOLDING  p)  states  that  p is  the  current  object  being  held  (for 
example  a puzzle  Piece).  If  the  hand  is  empty*  (HOLDING  NOTHING)  is 
in  working  memory. 

9.  (IN-HEAP  (PIECE  pc))  represents  puzzle  Piece  p as  being  in  a heap 
with  no  implicit  ordering  of  edges. 

10.  (LOOKING-AT  x)  states  that  object  x is  in  view.  If  nothing  is  in 
view  then  (LOOKING-AT  NOTHING)  is  in  working  memory. 

11.  (BEING-PUT-IN-PUZZLE  x>  represents  the  current  piece  x that  is 
actively  being  placed  in  the  puzzle. 

Production  Memory! 

LOQK-AT-PIECE--  IN-HFAP 
C (LOOKING-AT  =obJect)  $ =cl 
(IN-HEAP  (PIECE  =p  =c)  * ^object) 

— > 

(<delete>  =cl ) 

(LOOKING-AT  =obJeet)3 

L.OOK-AT-OB  JECT-IN-HANEi 
C (LOOKING-AT  =something)  $ *=cl 
(HOLDING  =obJect ) 

— > 

(<delete>  =cl) 
aOOKING-AT  -object)  3 

CLOSE-EYES 

C (LOOKING-AT  -something)  ♦ =cl 
-(LOOKING-AT  NOTHING) 

— > 

(<delete>  =cl ) 

(LOOKING-AT  NOTHING) 3 

OBJECT- IN-HAND- IN- VIEW 
C (HOLDING  -object ) 

(LOOKING-AT  ^object) 

-(LOOKING-AT  NOTHING) 

— > 

3 

PICK-UP-OBJECT-IN-VIEW 
L (HOLDING  NOTHING) 

(LOOKING-AT  =obJect) 

( 7 W— HEAP  — . i.  ini • t.  # » — c3 

— > 

( <delete>  =c3) 

(LOCKING*  AT  -cbJcct) 

(HOLDING  -object) 3 

1.2 


PUT-PIECE- DOWN- IN-HEAP 
C (HOLDING  (PIECE  »p  =c>)  % =cl 
(L00KIN6-AT  “object) 

— > 

(<delete>  =cl) 
(LOOKING-AT  * object) 
(HOLDING  NOTHING) 
(IN-HEAP  (PIECE  =p  *c))3 

FIND-COLOR-OF-PIECE 
C (LOOKING-AT  (PIECE  =p  -c>) 

(CURRENT-COLOR  “anything)  ♦ =c2 

— > 

(<delete>  =c2) 
(CURRENT-COLOR  “e)3 


FORGET-COLOR-OF-PIECE 
C (LOOKING-AT  (PIECE  “P  “c))  ♦ =cl 
(CURRENT-COLOR  “c>  * =c2 

— > 

(<delete>  -cl  =c2) 
(LOOKING-AT  NOTHING) 
(CURRENT-COLOR  NOTHING). 3 

PIECE-HAS-STRAIGHT-EDGE 
C (LOOKING-AT  (PIECE  »p  =c)) 

(SIDE  =sna  =p  0 »c ) 

— > 

3 

PIECE-HAS-CURRENT-COLOR 
C (LOOKING-AT  (PIECE  =p  “c>) 

(CURRENT- COLOR  =c) 

— > 

3 

HEAP-IS-EMPTY 

C-( IN-HEAP  “anything) 

— > 

3 

START-PUZZLE 

C-( IN-PUZZLE  -anythin*) 

(HOLDING  (F'lECE  -p  — c ) % ^object)  % =c2 
(LOOKING-AT  “object) 

-->( JOINED  ) 

(<delete>  =c2) 

(HOLDING  NOTHING) 
(IN-PUZZLE  “object) 
(LOOKING-AT  “object) 

( NUMBER- IN-PUZZLE  1)3 

PIECE-FITS- IN-PUZZLE 
C (LOOKING-AT  (PIECE  >p  -c)  * -object) 

“(iN-HUZZLfc  “Object) 

(IN-PUZZLE  (PIECE  -p2  -otherc)  I -otherp) 

(SIDE  -enw  -p  «n  -c> 

(SIDE  -another  -r2  (<nedotivc>  -r.)  -k> 

— > 3 


<<delete>  =c4  =c5  »c6) 
(BEING-PUT-IN-PUZZLE  =obJect) 
(LOOKING-AT  =obJect) 

(JOINED  • =rest  (=c4  =c5) ) 1 


PIECE-PUT- 1 N-F'UZZLE 

C (HOLDING  (PIECE  =c)  ♦ =obJect)  ♦ 
(NUMBER- IN-PUZZLE  =rr.)  * =c2 
-(IN-PUZZLE  =obJect ) 
(BEING-PUT-IN-FUZZLE  **obJect)  % -e4 


(<delete>  =cl  =c2  «=c4) 

(HOLDING  NOTHING) 

(LOOKING-AT  NOTHING) 

(IN-PUZZLE  =obJect ) 
(NUMBER-IN-PUZZLE  (<8ddl>  =n,))D 


F’UZZLE-IS-F  INI  SHED 
C (NUMBER-IN-PUZZLE  = 
( NUMBER-OF-F’IECES  * 
-(IN-HEAF’  =snythina ) 


( <halt> ) 3 
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Extensions  to  Jigsaw  Puzzle  Production  System 


Work ins  Memory? 

1«  (NUMBER-OF-PILES  m)  m is  the  number  of  Piles  we  have  (initially  0). 
2*  (CURRENT-PILE  n)  represents  the  current  Pile  we  are  using* 


3.  (ALL-PILES  p1  p2  • •»)  represents  all  of  the  piles  we've  made 
where  Pi  is  a unioue  integer  associated  with  a pile* 


4*  (PILE  i tl  t2  ««•)  represents  the  contents  of  Pile  i where  tJ  can 
be  any  object* 


Production  Memory? 


MANE-A-PILE 

C (HOLDING  ( <not>  NOTHING)  $ =obJect)  % *cl 
(LOOKING-AT  =obJect> 

(NUMBER-OF-PILES  =m)  ♦ =c3 
(ALL-PILES  ! = r ) % =c4 
(CURRENT-PILE  NONE)  * =c5 


— > 


(<delete>  ®cl  *c3  =c4  -c5> 
(NUMBER-OF-PILES  (<addl>  =m>> 
(LOOKING-AT  <=obJect) 
(ALL-PILES  (<addl>  =m)  ! «=r) 
(CURRENT-PILE  (<addl>  =m) ) 
(PILE  (<addl>  *m)  =nbJect) 
(HOLDING  NOTHING) 3 


PICK-A-PILE 

C (CURRENT-PILE  NONE)  ♦ 
(ALL-PILES  =Pl  « =r ) 


»cl 


— > 


(<delete>  =cl ) 
(ALL-PILES  *Pl  « = r ) 
(CURRENT-PILE  *p1)D 


PICK-OBJECT-FROM-PILE 
C (CURRENT-PILE  =Pl) 

(HOLDING  NOTHING)  4*c2 
(ALL-PILES  =Pl  ! *r) 

(PILE  “M  “object  ! «rest>  * 
(LOOKING-AT  “object) 


»c4 


W 


) 


— > 


<<delet.e>  «c2  *c4> 
(LUUMNU-ft I -Object) 
(HOLDING  “object) 
(PILE  “Pi  ! “rest ) 3 


II. 1 


PUT-OBJECT- IN-PILE 
C (CURRENT-PILE  =Pl> 

(HOLDING  ( <not>  NOTHING)  $ =obJect>  * =c2 
(LOOKING-AT  =obJect) 

(ALL-PILES  =Pl  ! =r  > 

(PILE  =p1  ! =rest)  * =c5 

— > 

(<delete>  =c2  =c5) 
(LOOKING-AT  *obJect> 
(HOLDING  NOTHING) 

(PILE  *p1  ! =rest  =obJ#ct)3 

FORGET-THIS-PILE 
C (CURRENT-PILE  =p1)  % =cl 
(ALL-PILES  =pl  ! =rest > $ =c2 

— > 

(<delete>  =el  =c2) 
(CURRENT-PILE  NONE) 
(ALL-PILES  ! =rest  =p1) 

PILE-IS-EMPTY 
C (CURRENT-PILE  =p1) 

(ALL-PILES  =pl  ! =rest ) 

(PILE  =p 1 ) 

— > 

3 

DESTROY-A-PILE 
C (CURRENT-PILE  =p1 ) * =cl 
(ALL-PILES  =p1  • =rest)  $ =e2 
(PILE  =p1  ! =r)  * =c3 

— > 

(<delete>  =cl  =c2  =c3 ) 
(CURRENT-PILE  NONE) 
(ALL-PILES  ! =rest ) 3 

THERE-ARE-NO-PILES 
C (CURRENT-PILE  NONE) 

(ALL-PILES) 

— > 

3 


LOOK-AT-F I RST- IN-PILE 
C (LOOKING-AT  sanuthini)  $ »cl 
(CURRENT-PILE  «p1) 

(PILE  *p1  «obJect  ! *rest) 

. — > 

(<delete>  *cl) 
(LOOKING-AT  >obJ«ct)3 


LOOK-AT-NEXT- IN-PILE 
L ( LUUK 1 Nb-A I ^object)  * «cl 
(CURRENT-PILE  *Pl> 

(PILE  — —••••. *»«i • i.  -IIHX  I.  I — r * » _,-3 

— > 


11*2 


(<dclete>  =cl  *c3) 

(LOOKING-AT  -r*e:it> 

(PILE  *=p1  «n*xt  I «r  »obJ*ct)3 
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